L'application se décompose en quatre package : 
\begin{itemize}
	\item le package client, qui comporte les éléments relatifs au client et à la gestion des communications
	\item le package file, qui contient les classes relatives aux fichiers
	\item le package utils, qui fournit des fonctions utilitaires
	\item le package decode, qui permet de gérer le message framing.
\end{itemize}

Nous ne détaillerons ici que les package principaux à savoir \textit{client} et \textit{file}. Cependant les diagrammes de classes des deux autres sont présents en annexes page \pageref{pack_utils} et \pageref{pack_decode}

	\subsubsection{Le package client}
		
		Le diagramme de classe du package client est présenté en annexes (page \pageref{pack_client}).
		Les classes présentes dans ce package ont les r\^oles suivants :
		\begin{itemize}
			\item \textbf{Client} permet de gérer les interactions avec l'environnement extérieur en centralisant les fichiers et les paramètres.
			
			\item \textbf{ClientServer} est le c\^oté serveur du client. Cette classe permet d'accepter des connexions d'autres pairs.
			
			\item \textbf{PeerConnection} permet de lancer un thread répondant aux demandes d'un pairs connecté à la partie serveur de notre client.
			
			\item \textbf{ClientTracker} permet de lancer le thread de mise à jour du tracker et celui de communication.
			
			\item \textbf{ConnectionToTracker} permet de communiquer avec le tracker.

			\item \textbf{ConnectionToPeers} permet de lancer un thread pour informer les pairs voisins de l'évolution du téléchargement relatif à un fichier et de lancer les threads s'occupant du téléchargement de ce dernier.
			
			\item \textbf{ConnectedPeers} gère la connexions aux pairs distants et du téléchargement d'un fichier.
			
			\item \textbf{UpdatePeers} permet d'informer régulièrement les pairs de l'avancement du téléchargement d'un fichier.
		\end{itemize}
		
	\subsubsection{Le package file}
		
		Le diagramme de classe du package file est présenté en annexes (page \pageref{pack_file}).
		Les classes présentes dans ce package ont les r\^oles suivants :
		
		\begin{itemize}
			\item \textbf{File} est l'élément central de ce package. C'est ce type d'objet qui contiendra les informations nécessaire au bon transit des fichiers sur le réseau.
			
			\item \textbf{BufferMap} permet de gérer le buffermap des fichiers.
			
			\item \textbf{CoupleIpPort} est utilisée pour stocker les pairs avec lesquels communiquer (sous forme de couple IP/port) lors du téléchargement d'un fichier.
			
			\item \textbf{FileCheckSum} permet de créer des clés uniques permettant d'identifier les fichiers, gr\^ace à des fonctions de hachage par rapport au contenu d'un fichier.
			
			\item \textbf{SharedFiles} apporte des fonctions utiles par rapport aux fichiers (création d'un fichier sur le disque, extraction des données d'une pièce, ajout d'une pièce au fichier sur le disque, ...).
			
			\item \textbf{Leech} est une implémentation servant aux stockage des fichiers leechés par un client. Cette classe permet d'utiliser un design pattern "Observer".
			
		\end{itemize}
	
	\subsubsection{Le multi-threading de l'application}
	
		Pour fonctionner correctement, toute application mettant en \oe{}uvre un protocole peer to peer se doit d'\^etre multi-threadée. En effet, ceci permet de répartir le téléchargement des pièces vers différents pairs, de gérer l'upload indépendamment et de permettre des mises à jours régulières que ce soit avec le tracker ou avec les clients distants.\\
		
		Un schéma explicatif de l'implémentation du multi-threading du client peut être trouvé en annexes page \pageref{schem_multithread}.\\
		
		De base, le client lance deux threads : le thread lui gérant la partie serveur auquel les pairs distants peuvent se connecter, et un thread de communication avec le tracker.\\
	Certains événements vont par la suite créer d'autres threads. Ces événements sont les suivants :
	\begin{enumerate}
		\item la connexion d'un pair au serveur
		\item la demande de téléchargement d'un fichier au tracker
		\item la mise à jour de la disponibilité d'un fichier en cours de download
	\end{enumerate}
	
	
		\paragraph{1. Cas de la connexion d'un pair au serveur\\}
			
			Lorsqu'un pair se connecte à la partie serveur de notre client, le thread qui sert à accepter les connexions entrantes crée un nouveau thread pour répondre aux demandes du client nouvellement connecté. On peut ainsi soit lui envoyer des informations telles que le buffermap du fichier par lequel il est intéressé, mais aussi les données qu'il peut \^etre amené à nous demander. Lorsque les demandes du clients ont été satisfaites, la connexion est alors fermée pour laisser la place à de nouveaux pairs.
			
		
		\paragraph{2. Cas de la demande de téléchargement d'un fichier au tracker\\}
		
			Lorsque l'utilisateur demande au tracker la liste des pairs associée à un fichier, le client reçoit un signal gr\^ace au \textbf{design pattern Observer}. Ce signal l'informe de l'ajout du fichier à la liste des \textbf{leech}. Le client se charge alors de lancer un thread par pair qui possède le fichier pour leur demander les pièces manquantes.\\
			
			De plus, pour se maintenir à jour, un thread permettant de gérer l'envoi des changements de buffermap associé à ce fichier sera lancé. On peut alors suivre la disponibilité du fichier à intervalle régulier.
			
		\paragraph{3. Cas de la mise à jour de la disponibilité d'un fichier\\}
		
			Dans le cas où un téléchargement se voit interrompu car il n'y a plus de parties disponibles sur le réseau, il se peut qu'à un moment un pair se connecte et possède les pièces manquantes. Dans ce cas, à la réception de son buffermap, la disponibilité du fichier est changée. Ce changement provoque l'envoi d'un signal au client qui va alors créer des threads pour reprendre le téléchargement depuis les nouveaux pairs.